1. Technical Field
The present invention relates in general to the field of computers, and in particular to networked computers. Still more particularly, the present invention relates to a method and system for controlling communication between a first node in a first network and a second node in a second network.
2. Description of the Related Art
Systems Network Architecture (SNA) is an architecture and set of implementing products for network computing within an enterprise developed by International Business Machines (IBM) or Armonk, N.Y. Details of this architecture are found in “Systems Network Architecture: Format and Protocol Reference Manual—Architecture Logic for LU Type 6.2 (SC30-3269)”, published by IBM, and herein incorporated by reference in its entirety. Capable of operating within the SNA architecture is Network Job Entry (NJE), which is a mechanism that allows host computer systems to transfer jobs, output, messages and commands between each other. Each host computer is a multi-user mainframe or midrange computer, the largest of which can support thousands of users. The host computer and its users are defined as a “node” (also called a “complex” or a “system”). Each “user” on the host computer is identified using a unique userid. All work on the computer, such as batch jobs, online transactions, time sharing sessions, system tasks etc., is associated with a specific userid for ownership purposes. Customers typically use their userid to gain access to the computer using client computers or workstations. While userids are used to identify customers or end-users requiring host computer services, they are also used to identify running applications and system tasks.
An NJE network is a group of two or more nodes that communicate with each other. With reference to FIG. 1a, an NJE network 102 is made up of Node A (104), Node B (106), Node C (108), Node D (110), and Node E (112). To become part of NJE network 102, each node's operating system must support an NJE facility (communication utility). Acceptable NJE facilities are JES2 (Job Entry Subsystem, Version 2), JES3 (Job Entry Subsystem, Version 3), RSCS (Remote Spooling Communications Subsystem), VSE/POWER (Virtual Storage Extended/Priority Output Writers, Execution Processors and Input Readers), and AS/400 Communication Utilities. Different nodes may use the same facilities, but are shown using a different named NJE facility in each of the nodes in FIG. 1a. 
Nodes can be classified as “originating,” “intermediate” or “target” nodes. With reference to FIG. 1b, assume that Node A (104) is sending data to Node D (110) to be processed, with the results printed on Node E (112). Node A, being the node where a user submitted a request to transmit data to another node, is the “originating node.” Node D is a target node where a NJE job (a transfer unit that contains data to be processed) is received for execution, and thus is called an “execution node.” Node E (112) is a target node where the results of the execution of the NJE job in Node D are sent, and thus Node E is called a “destination node.” Nodes B-C (106-108) lie in the path between Node A and Nodes D and E, and thus are called “intermediate nodes.”
Intermediate nodes simply pass through NJE data (or jobs) using a function known as “store-and-forward.” In the example of nodes shown in FIG. 1b, Node B and Node C do no validation of NJE work (data or jobs) being passed on to Nodes D and E. Thus, any security control of NJE data is only found in the originating node (Node A) and the target nodes (Nodes D and E).
When an NJE network consists of nodes that are all part of the same corporation or institution, then nodes are considered trusted and little or no security is required to control the ability of NJE data to pass through the network. However, sometimes an NJE network includes “semi-trusted” or “untrusted” nodes from outside the corporation. When this happens, the corporation must implement security policies to control unauthorized work from and to the non-corporate node(s).
Consider an NJE network 200 depicted in FIG. 2a. NJE network 200 includes a first node identified as Corporation ABC's NJE network 202, and second and third nodes identified as Node X (204) and Node Y (206). ABCSYS1, ABCSYS2 and ABCSYS3 are trusted nodes (a.k.a., “sub-nodes”) within Corporation ABC's NJE network 202. Since all users on the nodes ABCSYS1, ABCSYS2 and ABCSYS3 are part of the Corporation ABC's network 202, there is no need to control NJE data between these nodes. Now, assume that Node X (204) is a vendor supplier for ABC Corporation that has connected to Corporation ABC's NJE Network 202. Node X is not part of the ABC Corporation (and so is not a trusted node), but is considered to be a semi-trusted node, since only certain users on Node X are authorized to send work to ABCSYS1, ABCSYS2, or ABCSYS3. Node Y (206) is connected to Node X (204), and is therefore now also part of NJE network 200, and has access to Corporation ABC's network 202. However, since Node Y is not authorized to send work to ABCSYS1, ABCSYS2, or ABCSYS3, Node Y is considered an “untrusted node”.
ABC Corporation's security administrator must implement a security policy to control NJE traffic. The policy must allow authorized users from Node X to send data to ABCSYS1, ABCSYS2, and ABCSYS3. The policy must also delete any work arriving from Node Y. An example of such a policy profile is shown in FIG. 2b. Note that since security profiles can only be established at the originating or destination node according to NJE protocol, the security profile shown in FIG. 2b must be applied to every node (ABCSYS1, ABCSYS2, ABCSYS3) in Corporation ABC's NJE network 202. Similarly, the security administrators for Node X and Node Y would also likely want to set up similar profiles to protect Nodes X and Y from semi/untrusted nodes in Corporation ABC's NJE network 202. In a small configuration such as depicted in FIG. 2a, setting up such profiles in all nodes would require minimal effort. However, if Corporation ABC's NJE network 202 were made up of thousands of nodes supporting many subsidiary corporations (a common scenario), the necessary security administration would likely prohibit any NJE connections outside of Corporation ABC's NJE network 202.
What is needed, therefore, is an improved method and system of security checking that permits NJE data communication between NJE nodes. Preferably, such a method and system would be scalable with minimal adaptation.